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1  INTRODUCTION 

1.1  Background 

The  Battkfield  IMstributed  Simulation  -  Developmental  (BDS>D)  simulation  i»x>gram  has 
demonstrated  that  num-ui'the-loop  distribumd  interactive  simulation  systems,  including  an 
active,  intdligent  of^nsing  force,  can  explore  the  validity  of  planned  hardware  ctmUgutaticms  as 
well  as  the  concqMs  for  employment,  doctrine,  and  tactics. 

\2  PURPOSE  OF  THE  MDT2  TRAINING  EXERCISE 

The  objective  of  the  Muld-service  Distributed  Training  Tesd)ed  (MDT2)  Training  Exi^ise  was 
to  demonstrate  the  capability  to  conduct  meaningful  multi-service,  combat  nussion  training 
using  Distributed  Interactive  Simulation  (DIS)  technologies  and  synthetic  battlefields.  The 
focus  for  this  training  demonstration  was  close  air  support  (CAS).  The  Multi-Service 
Distributed  Training  Testbed  linked  simulations  and  simulates  of  all  four  Services  classified  at 
a  SECRET/NCX^RN  level.  Airframe  crew  simulators  of  Air  Force  pilots  at  Armstrong  Labs, 
Mesa,  AZ  (formerly  Williams  AFB,  AZ),  and  Marine  and  Navy  pilots  at  Systems  Engineering 
Test  Directorate,  Patuxent  River,  MD,  emulated  attack  and  forward  air  control  aircraft.  They 
supported  the  conduct  of  ground  force  operatitms  by  Army  elements  in  Advanced  Distributed 
Simulation  vehicles  and  Tactical  (Operations  Center  (T(X^)  at  die  Mounted  Warfare  Test  Bed 
(MWTB),  Fort  Knox,  KY.  Additionally,  a  Marine  Deployable  Forward  Observer  (DFO)- 
MULE  (ground  laser  designator)  team  participated  from  NRaD-San  Diego,  CA,  using  their 
target  identification  simulators.  The  key  to  the  demonstration  were  the  performance 
measurement  and  feedback  systems  used  f(^  the  CAS  training. 

U  PURPOSE  OF  THIS  DOCUMENT 

This  document  memorializes  the  authors’  observations  of  lessons  teamed  during  the  conduct  of 
the  MDT2  demonstration  with  reflect  to  conducting  this  sort  of  BDS-D  evolution.  It  does  not 
attempt  to  evaluate  either  the  effectivoiess  of  training  provided  to  soldiers,  airmen  and  marines 
during  the  demonstration  or  the  overall  suitability/operational  effectiveness  of  distributed 
simulation  as  a  medium  fw  delivering  CAS  training  such  evaluatitms  ate  left  to  the  project’s 
sponsor,  the  Army  Research  Institute  for  the  Behavioral  and  Social  Sciences  (ARI).  based  tm 
the  rqrorts  of  military  participants  and  the  observations  of  ARI  scieniists  and  their  suppon 
ctmtractor  staff.  The  mithors*  goal  is  n^ier  to  provide  inftKmation  that  will  be  of  use  to 
Simulatitm,  Training  and  Instrumentation  Command  (STRICUM)  and  Loral,  the  (m>viders  of 
BDS-D  services,  as  well  as  to  future  BDS-D  customers  who  may  wish  to  utilize  the  systnn  in 
^ilar  demonstiatitms. 
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1.4  ORGANIZATICm  OF  THIS  DOCUMENT 


The  remainder  of  this  document  is  organized  into  three  sections.  The  first  of  these  lists  the 
issues  identified  by  the  authors,  discusses  each  issue,  and  presents  recommendations  for 
solving  problems  similar  to  those  identified  during  the  conduct  of  future  demonstrations.  Next 
is  a  discussion  of  BDS-D  exit  criteria,  that  were  satisfied,  and  the  degree  to  which  they  were 
demonstrated,  during  the  MDT2  project.  A  final,  summary  section  lays  out  some  general 
conclusions  drawn  from  observations  of  the  demonstration  and  recommendations  based  on 
those  conclusions. 
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2  ISSUES,  DISCUSSIONS  AND  RECOMMENDATIONS 

2.1  ORGANIZATIONAL 

2.1.1  ComrdiiwtkHiofSites/AcdvHics 

lasilfi:  Tfiecoontination  of  operations  at  multiple  sites  equ^tped  with  simulations  of  difft^g 
ca|»Nilities  and  interoperating  through  eiq)erimental  interfaces  ret^tres  the  assignment  of  a 
senitM*  person  in  diarge  who  is  capabhs  al  examining  and  adjusting  both  technical,  operational, 
and  procedural  elements  of  die  demonstratitti  to  optimize  the  probabili^  of  success. 

Discussion: 

The  MDT2  demonstraticm’s  sponsor.  Dr.  Moses  of  ARI,  tasked  several  different  agencies  to 
pertkapate,  to  include: 

•  STRICOM/Loral  for  BDS-D  support  at  the  Mounted  Warfare  Test  Bed  •  tasked  with 
providing  the  ground  component  simulators  (less  dm  USMC  MULE  team)  and  Semi- 
Automated  Forces  (SAF) ,  the  Stealth/AAR  (After  Acdon  Review)  hardware  and  software 
capabilities,  a  Simulation  Network  (SIMNET)/DIS  Protocol  Transfer  hardware/software 
suite,  and  a  Defense  Simulation  Internet  (DSI)  network  interface . 

•  Armstrong  Labs  fw  F16  strike  aircraft  simulators  and  DIS  network  coordination. 

•  The  Naval  Air  Warfare  Center  Aircraft  Division,  Patuxent  River  for  an  Airborne  Forward 
Air  Controller  (AFAC)  simulator  and  provision  of  a  T1  line  to  link  Armstrong  Labs  to  the 
DSI  network. 

•  The  U.S.  Army  Armor  Center,  and  (through  the  center)  the  I94th  Separate  Armor  Brigade 
and  the  U.S.  Army  (Kentucky)  National  Guard  for  Observer  Controllers  and  exercise 
participants. 

•  The  Naval  Air  Warfare  Center,  Training  Systems  Division  (NAWC/TSD)  and  NRaD  for  a 
MULE  team  simulsdion. 

•  ARI/  Human  Resources  Research  Organization  (HuraRRO)  for  data  collection  and 
analysis. 

•  Jim  Love,  ARI  consultant,  for  scenario  development . 

•  DCI/Defense  Modeling  and  Simulation  Office  (DMSO)/Houston  Associates  to  provide 
access  to  die  DSI  net 

(See  Appendix  B  for  a  list  of  participants  at  Ft  Knox.) 

The  problems  encountered  during  the  first  week  of  preparations  for  the  MDT2  exercise 
involved  a  great  deal  of  troubleshooting.  Problems  different  in  nature  and  different  in  location 
had  to  be  dealt  with.  There  was  no  single  person  directing  diis  effort 
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The  person  who  developed  the  MDT2  concept  and  coordinated  ti»  project  as  a  whole  jnrior  to 
this  on-site  exercise  preparation  was  Dr.  Frank  Moses  of  ARL  During  the  exercise  Dr.  Moses' 
role,  however,  had  shifted  to  that  of  primarily  non-interference  and  observation.  His  goal 
apparently  was  not  to  unduly  influence  the  outcome  of  the  exercise.  This  left  the  key  players, 
both  at  Ft  Knox  and  the  other  sites,  to  coordinate  and  interact  with  each  other,  but  without 
overall  direction  from  one  source.  The  result  was  some  confusion. 

♦ 

Col.  Don  Elder  of  the  Armor  Center,  (supported  by  Col.  Mike  Rodriquez  USAF),  was 
designated  the  chief  trainer  for  the  exercise,  but  he  was  not  familiar  with  the  other  sites  and  had 
provided  no  input  into  the  scenario  developntent  or  simulation  organization.  He  was  not  given 
detailed  information  on  the  capabilities  of  the  simulators  at  all  four  sites.  He  could  not, 
therefore,  optimize  the  scenarios  used  in  conjunction  with  the  equipment  on  hand  and  the 
designated  procedures.  He  indicated  during  first  week  discussions  that  he  saw  his  mission  as 
taking  the  hardware,  software,  communications  links  and  scenario  as  a  given;  attempting  to  train 
CAS  in  that  milieu;  and  reporting  whether  training  occurred  or  not 

Steve  Farrow,  the  LORAL  Program  Manager  (PM)  at  Ft  Knox  seemed  to  become  the  de-facto 
DSI  coordinator  among  the  sites  (since  Armstrong  Labs  was  not  plugged  directly  into  the  net 
but  rather  connected  via  T- 1  line  from  Pax  River,  it  was  impossible  for  Herb  Bell  at  Armstrong 
to  monitor  the  network's  health  and  coordinate  the  sites).  Steve  and  his  staff  spent  hours  on  the 
telephone  with  Houston  Associates  -  their  contact  for  long  haul  network  problems,  only  to  find 
that  the  secure  (red)  net,  however,  was  still  the  responsibility  of  Bolt,  Beranek,  and  Newman 
(BBN)  in  Cambridge,  but  in  transition  to  Houston  Associates,  so  Houston  was  of  little  help,  at 
least  during  the  first  week. 

Recommendation:  It  is  recommended  that  in  projects  of  this  nature  and  scope,  the  responsibility 
of  pulling  all  the  bits  and  pieces  together  should  be  given  to  a  senior  operational  person  who  is 
familiar  with  simulation  and  has  the  authority  to  direct  any  person  that  can  make  it  woric.  It  is 
felt  that  since  the  focus  of  this  exercise  was  training,  the  most  suitable  candidate  for  this  role 
would  have  been  Col.  Elder.  His  involvement  should  have  started  at  the  beginning  with  control 
of  scenario  development,  personnel  assignments,  etc.  and  visits  to  each  site  to  fully  understand 
the  attributes  and  idiosyncrasies  of  each  simulation  system  from  an  operational  point  of  view . 
His  mission  should  have  been:  "Here  is  a  suite  of  simulation  equipment  at  these  four  sites. 
These  are  the  capabilities  and  limitations  of  the  equipment  Here  are  the  available  troops  and 
contractor  support  people.  The  goal  is  to  train  CAS.  Make  it  work  if  at  all  possible  and  report 
results.”  Given  that  mission  he  could  have  optimized  the  scenario,  identified  the  important 
"glitches"  in  the  various  simulators  that  needed  fixing,  and  put  in  place  0/C  and  troop 
procedures  to  fill  in  for  simulation  shortcomings  where  appropriate.  In  fact,  COL  Elder  and  his 
staff  evolved  into  this  role  over  the  course  of  the  demonstration,  but  had  he  been  so  assigned 
from  the  outset  of  the  project,  many  problems  would  have  been  avoided  and  technical  efforts  to 
prepare  for  the  demonstration  would  have  been  better  focused  in  cridcal  areas. 

The  person  responsible  for  DSI  coordination  and  liaison  should  be  at  a  site  that  is  a  DSI  node. 
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2.1.2  Coordination  of  Schedules 

ISSUfi:  The  four  sites  used  in  this  exercise  span  three  time  zones.  Schedules  for 

participants  at  each  location  must  be  coordinated  to  allow  fex*  network  availability,  meal  breaks 
and  n(»mal  working  hours. 

Discussion:  The  schedutes  planned  for  this  exercise  did  allow  for  differences  in  times  zones, 
and  thetefOTe.  the  actual  exercise  time  is  somewhat  limited.  A  time  of  1 1:00  a.m..  Eastern 
Standard  Time  was  set  for  the  start  of  the  exercise.  It  appeared  difficult  to  get  all  sites  up  and 
ready  at  this  time.  Delays  due  to  various  reasons  occurred  causing  the  stan  of  the  exercise 
close  to  at  the  designated  lunch  break  at  the  Ft  Knox  site. 

Recommendation:  To  get  the  maximum  benefit  from  the  limited  times  available,  it  is  cruci^  that 
all  preparations  be  made  prior  to  the  official  start  time  and  that  an  earlier  start  time  of  10:00 
a.m..  Eastern  Time  would  be  preferable.  Technical  problems  should  be  addressed  prior  to  this 
time,  if  possible.  Briefings  should  be  completed  and  personnel  should  be  ready  to  start  tactical 
play  at  10:00. 

2.1.3  Assignment  and  Tasking  of  Test  Subjects 

ISSUfi:  A  determination  must  be  made  as  to  the  personnel  requirements  at  each  location  with 

respect  to  their  skill  level,  functions,  experience  and  their  role  in  this  exercise. 

Discussion:  The  major  personnel  tasking  issue  noticed  during  this  first  week  of  MDT2  was 
discussed  in  Section  2.1.1.  the  lack  of  one  operational  person  to  take  charge  of  the  whole 
exercise.  There  also  seemed  to  be  some  areas  where  additional  test  subjects  were  needed.  This 
was  particularly  true  in  the  TOC.  This  station  was  understaffed  and  staffed  only  with  officers. 
It  also  iqipeared  that  the  pilots  at  Armstrong  were  changed  frequently  and  participated  for  only 
short  periods  of  time.  At  the  Knox  site,  the  lead  technician  was  moved  to  Ft  Beiuiing  just  prior 
to  diis  exercise,  leaving  the  site  understaffed  by  one. 

The  original  assignment  of  roles  to  participating  troops  was  found  by  the  0/Cs  to  be 
inappropriate.  Since  platoon  leaders  play  no  tele  in  CAS,  dedicating  simulators  and  troops  to 
play  diese  roles  was  found  not  to  contribute  to  training. 

Although  four  personnel  were  requested  at  NRaD  for  the  MULE,  they  did  not  all  show  up. 

Pilots  at  Armstrong  rotated  through  the  exercise,  so  that  seldom  were  the  same  pilots  used  on 
successive  days. 

Reemnmendation:  Some  of  the  personnel  issues  were  noted  during  this  first  week  and  some 
changes  were  made.  Col.  Eltto*  recommended  having  a  more  representative  staff  in  the  TOC.  A 
change  in  the  organization  of  personnel  in  the  TOC  area  occurred  for  the  actual  exercise. 

The  availability  of  simulators  and  SAF  vehicles  should  be  considered  early  in  scenario 
development  and  personnel  assignments. 
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Ai^gements  for  backup  personnel  should  made.  It  is  also  recommended  that  the  number  of 
different  pilots  used  in  this  or  any  exercise  of  this  nature  be  kept  at  a  minimum.  Different 
players  bring  in  another  variable  into  the  exercise.  Although  in  reality  new  pilots  may  be 
brought  in  for  every  CAS  mission,  the  limitations  and  work-arounds  necessary  in  the  early 
veraons  of  this  type  of  training  necessitate  the  use  of  a  stable  group  of  pilots.  Since  the  amount 
of  time  pilots  can  remain  in  simulators  is  more  limited,  two  sets  of  pilots  would  be  acceptable  to 
allow  for  relief. 

2.2  TECHNICAL 

2J2,1  Local  Simulation  Network 

There  were  no  significant  problems  in  this  area.  A  couple  of  simulators  crashed  but  were 
quickly  brought  back  on  line. 

2.2.2  DSI  Network 
2.2.2. 1  Protocol  Translator 

Issue:  The  translating  systems  at  each  site  must  be  capable  of  transferring  Protocol  Data 

Units  (PDUs)  across  the  net 

PificiKsinn-  Different  translating  systems  were  used  at  the  sites  in  this  exercise.  Both 
Armstrong  and  NRaD  used  the  NIU  interface  units.  Pax  used  an  AIU  interface  unit  and  Ft. 
Knox  has  the  SIMNET  DIS  Protocol  Translator.  There  were  problems  in  the  abili^  of  these 
various  systems  to  adequatdy  read  and  translate  the  PDUs  being  sent  on  the  DSI  net: 

•  Pax  River  could  not  translate  the  Fire  and  Detonation  PDUs  and  therefore  could  not  see  that 
their  aircraft  was  being  fired  at  by  SAF  ZSU  23s  (Soviet  Air  Defense  vehicle)  at  Ft.  Knox 
nor  was  there  any  effect  if  a  hit  did  occur. 

•  Indirect  fire  could  not  be  seen  at  NRaD  because  it  originated  from  the  SAF  operator 
sending  detonation  PDUs  and  did  not  have  a  source  vehicle  attached  to  it  This  caused  it  to 
crxne  across  as  a  bad  packet  at  NRaD. 

•  Lases  were  n<»  translated  at  Ft  Knox  because  SIMNET  does  not  have  a  lose  PDU. 

B^oPtniendatimi:  Pax  River  is  in  the  process  of  revising  their  AIU  interface  unit  and  had  they 
had  sufficient  preparation  time  prior  to  the  start  of  this  exercise,  most,  if  not  all  of  these 
problems  could  have  been  eliminated.  Sufficient  time,  not  technical  capability  swra  to  have 
caused  this  prc^lem.  TlK^se  technical  issues  arc  still  being  worked  on  and  the  systems  will  soon 
be  capable  of  effective  protocol  transfer.  This  is  also  the  case  at  the  other  sites,  however,  if  a 
translatioa  problem  still  exists^at  the  time  of  future  exercises,  the  impact  of  this  problem  must  be 
aaaifyzti  and  alternative  solutions  sought 

Although  a  PDU  may  not  seem  to  be  required  at  one  site  vs.  another,  the  abilit>'  to  process  these 
may  often  be  required  to  effectively  troubleshoot  system  problems.  A  case  in  poiiu  is  the  lasing 
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PDU.  It  was  tmpo^ble  fcM*  the  Chief  Trainer.  0/C  staff  and  tecimical  staff  at  Knox  to 
detennine  why  laser-gitided  Ixmibs  on  a  pieviraisly  lased  taxTga.  radier  dun  die  (me  cmendy 
being  lased. 

2.2.2.2  SnfficieDt  PDU  Update  Rates/Bandwidth 

IsMie:  the  cttsumi^  (in  this  case  the  overall  MDT2  project  managra*)  and  die  supfdier  of  DSl 
services  needs  to  be  ^le  to  pretfict  in  advance  what  the  netwrak  baiKlwiddi  requiranents  will  be. 
No  standard  way  to  estimate  lequirements  seems  to  have  been  used  here.. 

Discuaskm:  For  the  bandwidth  to  be  sufficient  for  an  exercise  of  this  nature,  other  users  on 
the  network  must  be  kept  to  a  minimum.  The  fluctuation  in  die  PDUs  tranrferml  across  the  net 
vary  with  die  activities  of  die  exercise.  Insufficient  bandwidth  at  peak  usage  may  have  been  one 
of  the  factors  iesp<»sible  for  repeated  down  time  of  die  DSI  netwrak. 

RecomiBMiAirirw  Sufficient  testing  should  be  done  prior  to  the  execution  of  an  exercise  of  diis 
nature  so  as  to  determine  peak  bandwidth  requirements.  A  standard  method  for  calculating 
bandwidth  requirements  should  be  developed  by  the  DSI  operating  agency  and  provided  to 
potential  users.  Such  a  system  might  require  exercise  developers  to  fill  out  questionnaires 
listing  numbos  and  types  of  simulators  and  voice  radio  channels,  estimates  of  various  types  of 
engagements  and  simultaneous  voice  radio  messages  and  the  like.  DSI  schedulers  could  then 
translate  the  information  into  bandwidth  numbers. 

2.2.2.3  Reliability/Availability 

Issue:  The  long  haul  network  must  be  available  for  the  times  allocated  to  this  exercise  and 

must  be  reliable  during  tiiose  periods  of  time  to  minimize  any  disruptirai  of  the  exercise. 

Di.scus«ion!  During  the  course  of  this  exercise,  one  of  the  key  difficulties  was  the  reliability 
of  die  DSI  network.  In  some  cases  it  crashed;  in  others,  the  exercise  was  out-prioritized  by 
other  network  demands,  resulting  in  a  less  than  70%  availability.  In  addition  to  the  bandwidth 
problems  discussed  in  Section  2.2.2.2,  other  technical  problems  seem  to  have  effected  the 
rdialtility  of  die  network. 

During  a  post-exerdse  meeting  at  Armstrong  Labs  it  was  noted  diat  not  only  was  the  networic 
not  relud^  doting  the  rehearsal  and  rest,  H  was  equally  unreliable  during  pre  -demonstration 
testing,  forcing  tire  techtucal  team  to  truncate  their  system  rest  and  check-out  procedures.  The 
results  were  predictable. 

ReccMnmeiMteitwi;  DSI  reliability  is  critical  to  the  successful  evaluation  of  the  use  of  simulatitm 
across  the  long-haul  network.  When  unknown  technical  factors  affect  the  reliability  of  the 
netwcnk  dutmg  the  ccmrse  of  an  exocise,  open,  admiiustrative  commuitication  lines  should  be 
available  between  those  individuals  who  can  direcdy  evaluate  and  fix  the  problem.  [See 
.A4)pendix  C:  The  attach^  memo  dared  May  16, 1994  from  I^.  Moses  to  DMSO  after  the  first 
week  provides  a  clear  statement  of  the  problems  with,  and  concerns  about  the  DSI  network.]. 


MJutwl^ 


Netwotk  availability  and  reliability  prior  to  the  demonstration,  daring  the  weel^  and  months  of 
system  integration  and  test,  is  equally  important 

2.2.2.4  MDT2  Network  Management 


ISiSys;  Management,  control  and  submission  of  overall  network  requirements  should  be  with 
one  individual. 

Discussion:  Herb  Bell  at  Armstrong  was  assigned  to  manage  the  network,  yet  he  was  at  the 
one  site  that  was  not  on  the  DSI  net  directly.  The  center-of*mass  of  the  exercise  was  at  the 
Knox  site,  yet  there  was  no  direct  communications  link  between  Knox  and  Houston/BBN. 

Recommendation:  Management  of  the  network  activities  should  be  given  to  one  individual  at 
the  largest  site  in  the  exercise  that  is  a  node  on  the  DSI  network..  This  individual  should  be 
involved  with  the  estimations  of  exercise  bandwidth  requirements  and  coordination  with 
Houston  Associates.  Net  requirements  should  be  analyzed  with  regard  to: 

•  Tactical  nets 

•  0/C-  Video  Teleconference  (VTC)  nets 

•  Administrative/Technical  coordination  of  nets 


Determinations  should  be  made  with  regard  to  using  the  DSI  net  for  all  communication 
requirements.  In  the  case  of  Administrative/Technical  communication  requirements,  a 
conference  call  hook-up  via  AT&T  provides  a  redundant,  reliable  and  practical  solution. 

2.2.3  Virtual  Battlefleld 


2.2.3. 1  Terrain  and  Natural  Environment  Correlation 

Issue:  The  terrain  displayed  at  all  the  sites  must  sufficiently  correlate  with  respect  to  its 

elements,  e.g,  altitude,  texture,  color,  etc. 

Discussion:  Different  terrain  databases  (all  of  the  Naval  Training  Center  (NTC))  were  used 
at  the  different  sites  in  this  exercise.  Armstrong  and  Pax  used  the  same  database;  NRaD’s 
system  used  a  database  correlated  with  a  few  still  photographs;  and  Ft.  Knox  had  still  another 
database.  At  times  during  the  course  of  this  exercise,  these  databases  were  not  matched  up 
properly.  Once  the  problem  was  identified,  there  were  technical  work-around  solutions 
avaUable. 

Recommendation:  The  use  of  a  consistent  terrain  database  between  all  sites  would  ameliorate 
this  kind  of  problem.  However  this  is  also  interrelated  with  the  different  kinds  of  simulation 
systems  used  at  each  site  and  the  different  ways  they  operate  on  the  database  to  represent  the 
world.  Therefore,  correlation  tests  should  be  run  during  exercise  preparadorw  by 
selecting  various  terrain  features  and  having  all  stations  report  the  locations  and 
view  entities  placed  at  those  locations  by  each  of  the  systems  with  all  appropriate 
sensors. 
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2.2.3.2  Granularity  of  Terrain  £>atabase 

Issue:  The  level  of  (tetail  of  the  terrain  database  at  each  site  must  be  sufficient  to  support 

the  functions  required  of  each  system  in  diis  exncise. 

Disc».«ion;  The  terrain  database  varies  at  the  different  sitBS  used  in  this  exercise.  This  is  due 
to  the  fact  that  each  terrain  was  developed  specifically  for  its  own  system.  The  visual 
representation  of  the  terrain  that  an  F16  pilot  s^  out  his  window  is  very  different  than  the 
terrain  seoi  by  the  crew  an  Ml  Al.  At  times,  the  AFAC  was  seen  at  Fort  Knox  to  fly  tiurough 
hills  •  due  to  the  fact  that  variations  in  relief  are  calculated  more  densely  in  the  terrain  database 
at  Ft.  Knox,  resulting  in  a  more  detailed  (albeit  mote  limited  in  area)  terrain  definition  than  that 
available  in  the  flight  simulator  databases.  Thus,  the  peaks  seen  at  Ft  Knox  may  not  be  seen  at 
Armstroiig,  and  therefore  it  will  i^pear  at  Knox  as  if  the  planes  are  flying  tiirough  hills. 

Recommendation:  Until  such  time  as  the  technology  allows  us  to  produce  consistent  levels  of 
granularity  in  all  the  terrain  databases,  this  discrepancy  will  continue  to  occur.  The  terrain  and 
tactics  chosen  in  scenarios  should  try  to  minimize  these  differences.  The  planes  should 
continue  to  tactically  fly  as  they  normally  would  according  to  their  own  visual  system. 

2.2.3.3  Artifacts  of  the  Simulation 


Issue:  The  virtual  battlefield  must  be  free  of  artifacts  that  can  impose  unrealistic  constraints 

or  advantages  on  combatants  during  the  exercise. 

Discussion:  For  the  purposes  of  this  exercise,  the  F16  pilot  had  to  detect  and  identify  the 
vehicles  on  the  ground.  It  was  discovered  that  this  was  not  always  the  case.  Ground  vehicles 
were  usually  visible  on  the  flat  terrain  but  not  when  they  were  moving  in  the  hilly  areas.  The 
problem  may  be  one  of  color  contrast  between  the  vehicle  and  the  ground  as  seen  on  the  F16 
simulator  Computer  Image  Generator  (CIG).  The  contrast  may  not  be  great  enough  for  the 
planes  to  detect  the  targets  in  the  hilly  areas. 


Recommendation:  Detection  tests  should  be  performed  to  see  where  on  the  terrain  database  the 
ground  vehicles  are  not  being  seen.  The  scenarios  should  be  altered  slightly  to  move  the 
ground  vehicles  to  locations  where  the  F16  pilots  can  realistically  detect  the  targets.  It  is 
important  to  remember  that  the  only  purpose  of  the  simulation  is  to  provide  reasonably  realistic 
cues  to  stimulate  proper  solder-to-soldier  and  soldier-to-airman  coordination  and  control 
activities. 


2J2A  Moving  Models 


2.2.4. 1  Consistency  of  Iconic  Representation 

Issue:  The  icons  used  for  entities  must  be  clearly  representative  of  their  appearance  in  the 

real  world. 
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Di.scmsinn:  Several  entities  in  this  exercise  were  using  icons  which  did  not  represent  what 
they  actually  were;  the  icon  used  to  represent  the  MULE  was  a  single  dismounted  soldier;  the 
icon  used  to  represent  the  OV-10  was  an  A-IO.  Both  these  representations  did  not  appear  to 
cause  any  problems  in  the  performance  of  the  exercise.  There  were,  however,  a  few  more 
bizarre  mismatches  that  occurred  within  specific  simulators  at  the  Knox  site  during  the  exercise 
(BMPs  (Soviet  Armored  Personnel  Carrier)  showing  as  "beach  balls")  that  caused  problems. 

Recommendation:  The  Data  Element  Dictionary  (DED)  should  be  checked  in  all  simulators 
prior  to  the  exercise.  If  proper  icons  are  not  available  at  the  time,  the  most  reasonable 
substitutes  should  be  assigned. 

2.2.4.2  Limits  of  Numbers  of  Moving  Models  Processed/Displayed  (Prioritization) 

Issue:  The  simulation  systems  used  at  each  site  in  this  exercise  have  different  capabilities 

with  respect  to  the  number  of  moving  models  they  can  process  simultaneously.  Prioritization  of 
the  iconic  representations  had  to  be  used  due  to  these  limitations. 

Discussion:  Ft  Knox  has  the  capability  of  representing  all  the  moving  models  involved  in 
this  exercise;  however,  this  is  not  the  case  at  the  other  sites  participating.  The  MULE  at  NRaD 
is  a  system  that  can  only  display  5  entities  on  the  battlefield  and  these  are  prioritized.  If  an 
entity  with  a  higher  prioritization  enters  the  field,  the  lower  priority  vehicle  drops  off  the  leaain. 
The  F- 16s  at  Armstrong  also  have  a  limited  number  of  entities  they  can  display.  The  AFAC 
simulator  at  Pax  River  could  initially  see  only  the  first  16  moving  models  loaded  on  the 
database .  This  limitation  caused  a  major  problem  in  the  performance  of  the  AFAC.  Prior  to  the 
second  week  of  the  exercise,  however,  technicians  were  able  to  make  some  changes  in  the 
manner  in  which  the  16  moving  models  to  be  displayed  were  prioritized.  The  16  moving 
models  displayed  subsequently  were  those  in  closest  proximity  to  the  AFAC.  As  the  view 
would  change  from  the  AFAC,  the  1 6  models  displayed  would  also  change. 

Recommendation:  Due  to  the  limitations  of  the  technology  at  this  point  in  time,  careful  analysis 
should  be  performed  to  construct  the  scenarios  and  adjust  simulation  prioritization  schemes  so 
that  the  most  tactically  significant  entities  are  visible  to  each  player  on  the  battlefield.  This 
analysis  needs  to  be  done  at  a  very  early  stage  of  the  system  integration  process. 

2.2.4.3  Vulnerability 

Issue:  The  effects  of  any  engagement  should  parallel  real  life. 

Discu.«inn:  Due  to  some  technology  limitations  (in  this  case,  a  DIS  translating  problem),  the 
ZSU-23s  firing  had  no  effect  on  the  AFAC,  making  it  invulnerable.  This  did  not  allow  for  a 
realistic  fight  The  impact  on  the  CAS  tactics  of  the  participants  was  great.  The  AFAC  did  not 
report  the  fire,  did  not  leave  the  area,  did  not  get  killed,  and  did  not  call  for  a  Suppression  of 
Eriemy  Air  Defense  (SEAD)  mission  or  other  support 

RflCninmfifHfatinn:  A  work-around  might  have  been  to  have  the  0/Cs  announce  to  the  OV-10 
whenever  the  ZSU  engaged  him,  noting  the  location  and  type  of  fire  and  effects.  When 
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discrepancies  in  vulnerability  occur  and  a  wtHic-around  solution  cvuiot  be  found,  eliminmion  of 
one  of  the  entities  may  be  the  answer.  Tte  point  here,  again,  is  that  early  in  tlw  system 
integration  process,  the  operational  impacts  of  mchnology  limitations  must  be  identified. 

2.2.5  Coi^iruence  of  X,Y,Z  location 

Issue:  Entities  on  and  features  of  the  terrain  database  should  have  consistent  x,  y,  z 

locations. 

Discu.ssion:  Due  to  the  discontinuity  of  the  terrain  databases  at  the  different  sites,  the  entities 
positioned  at  one  site.  e.g.  Ft  Knox,  may  appear  to  be  floating  above  ground  or  positioned 
underground  at  another  site.  In  addition,  planes  flying  at  the  Armstrong  site  close  to  ground 
level  may  appear  to  fly  underground  at  Ft  Knox.  The  disparity  appears  to  be  due  to  the 
differences  in  the  "y"  axis  of  the  terrain  databases.  The  situation  also  applies  to  air-dropped 
bombs  and  marking  rockets  (sometimes  diey  exploded  "underground")  and  makes  the 
interaction  between  controlling  agencies  at  die  various  sites  very  difficult 

Recommendation:  A  method  of  referencing  entities  to  the  ground  (y  s  o)  has  been  developed 
called  "ground  clamping".  This  allows  ground  vehicles  to  appear  on  the  ground  at  each  site.  It 
also  kept  marking  rounds  and  bombs  from  detonating  underground  (although  in  the  case  of 
bombs,  it  produced  bizarre  visual  effects  at  Ft  Knox  -  flaming  bombs  skidding  along  the 
ground).  This  methodology  could  not  be  applied  to  the  planes  flying;  however,  "flying  through 
hills"  was  corrected  by  keying  the  AFAC  at  a  slightly  higher  tdtitude.  It  is  essential  that  the 
views  at  each  site  in  this  exercise  be  consistent  An  analysis  should  be  performed  in  the 
preparation  stages  of  an  exercise  by  putting  each  participating  moving  model  (to  include 
ordnance  impacts)  out  in  the  terrain,  observing  it  from  all  systmns  and  comparing  appearances/ 
location  data. 

2.2.6  Load  Gmimiinications 

2.2.6. 1  Tactical 

Issue:  Communications  between  players  within  a  site  should  be  consistmit  with  die  normal 

onnmunication  lines  available  to  troops  in  a  comparable  real  tactical  situation. 

Di.scM.«inn!  The  site  with  the  greatest  number  of  players  and  with  the  need  for  local 
communicatkms  was  Pu  Knox.  There  were  5  MlAl  tank  simulators,  2  Bradley  simulators,  a 
simulated  TCX!  and  the  stealth  station.  Initially,  the  Air  Liaison  Officer  (ALO)  and  Fire 
Support  Officer  (FSO)  had  been  placed  in  an  MlAl  simulator  with  one  radio  operating  three 
radio  nets.  The  function  of  these  two  positions  require  that  they  operate  two  radios 
simultaneously.  This  was  not  feasible  with  the  current  configuration  in  this  simulator,  so  a 
TA312  field  phone  was  wired  into  the  simulator  to  allow  conversation  with  the  T(X.  This 
communicatitm  prcdilem  and  the  simulator  assignment  issues,  sectitxi  23.4.4,  were  both  solved 
by  putting  the  ALO  in  the  TOC;  the  Enlisted  Terminal  ^tackCcmtroller  (ETAC)  n^laced  the 
ALO  in.the  tank,  the  FSO  went  to  the  TOC  during  the  Offmise  scenario  and  went  to  a  diffinent 
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tank  from  the  ALO  during  the  Defense  scenario.  In  addidon.  the  scouts  in  the  two  Biideys  felt 
they  needed  their  own  internal  net  to  communicate  with  each  other  during  the  defensive 
scenario.  The  decision  was  made  that  they  would  communicate  on  the  Fire  Net.  It  was  also  felt 
that  the  information  coming  to  the  TOC  across  the  intel  net  was  weak.  This  was  not  purely  a 
communicadon  problem,  however,  the  solution  was  to  set  up  a  CB  radio  from  the  stealth  station 
so  that  proper  intel  could  be  communicated. 

Recommendation:  Careful  pre-exercise  analysis  should  be  performed  to  determine  the  local 
tactical  communication  needs  based  on  the  scenarios  used  and  the  functions  of  the  troops 
during  the  course  of  each  scenario.  Simulator  assignments  and  upgrades  (temporary  or 
permanent)  to  simulators  can  be  made  accordingly. 

2. 2.6.2  Technical/Administrative 

Issue:  The  status  of  the  exercise  participants  should  be  provided  to  the  Observer/Controller 

(O/C),  Technical  and  Administrative  staff. 

Discussion:  During  the  course  of  the  exercise,  there  was  oftei.  confusion  as  to  the  status  of 
the  network,  of  various  simulators  and  of  the  SAF. 

Recommendation:  It  is  recommended  that  a  real-time  status  information  display  be  set  up  at  the 
stealth  station,  easily  visible  to  the  0/Cs.  that  shows  which  simulators  are  up  and  which  other 
sites  are  connected. 

2.2.7  Long  Haul  Communication 

2.2.7. 1  Tactical 

Issue:  Bandwidth  requirements  for  tactical  voice  traffic  should  be  determined  in  the 

planning  stages  of  an  exercise. 

Di^ussion.  The  tactical  requirements  drive  the  volume  of  voice  communications  across  the 
long  haul  network.  Peak  bandwidth  requirements  can  crash  the  net  if  enough  bandwidth  has 
not  been  allocated.  (See  Issue  2.2.2.2) 

Recommendation:  Estimate  peak  voice  traffic  demands  based  on  the  tactical  scenarios,  prior  to 
requesting  bandwidth  allocations. 

2. 2.7.2  Technical/Admira’strative 

Issue:  Communication  lines  between  0/Cs  should  be  direct  and  separate  from  tactical, 

technical  staff,  and  other  communications.  Technical  staff  at  all  sites  should  also  have  a 
separate  communications  line 

Discussion:  During  the  first  week  of  this  exercise,  the  only  communication  line  between  the 
controllers  at  all  the  sites  was  via  the  DSl  network.  When  the  DSI  net  was  down  at  one  or  more 
sites  no  work-arounds  could  be  arranged  because  O/C  communication  was  down.  The  decision 
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was  made  to  have  commercial  phones  placed  at  the  O/Cs  station  at  each  site  and  to  try  to 
maintain  an  open  phone  line  between  them.  This  was  accomplished  during  the  second  week  of 
the  exercise. 

Recommendation:  Since  communication  between  Q/Cs,  and  between  technical  personnel 
should  not  interfere  with  the  tactical  conduct  of  an  exercise,  separate  communication  lines 
should  always  be  installed.  These  should  not  use  the  DSI  network.  ATT  Conference  Calls 
seem  to  be  a  reasonably  cost-effective  apjHoach  to  this  requiiemenL 

23  Training/Scenarios 

23.1  Troop  Training 

Issue:  Troops  must  be  simulator-trained  and  position-trained  prior  to  being  used  in  an 

exercise  which  focuses  on  evaluating  tactical  training  tools. 

Discussion:  All  the  troops  present  at  the  Ft.  Knox  site  had  previous  expe  '  with 

simulation.  Our  belief  is,  however,  that  this  was  the  luck  of  die  draw.  Nofamilian.  n  class 
for  the  simulators  had  been  scheduled;  it  pn^ably  should  have  been.. 

The  troops  assigned  to  one  of  the  two  Bradleys  were  instructed  to  operate  the  Bradley  as  if  it 
were  a  Fire  Support  Team  (FIST).  They  woe  not,  however,  tactically  trained  as  a  FIST. 

Recommendation:  Troops  should  be  placed  in  the  positions  and  vehicles  for  which  they  .re 
trained.  If  they  are  not  sufficiently  trained,  this  may  affect  the  results  of  the  exercise  and  the 
evaluation  of  the  training  system.  Some  time  should  always  be  allotted  for  simulator  training. 

23.2  AAR 

2.3.2. 1  Visualization  and  Display  Tools  (Stealth,  PVD,  SIMNET  6.6. 1  Datalogger) 

Issue:  The  use  of  display  tools  and  the  visualization  of  the  exercise  should  be  maximized 

during  the  preparation  and  conduct  of  an  AAR. 

Discussion:  TCK!  Plan  View  Display: 

A  plan  view  display  was  placed  in  the  'TOC  area  (not  visible  to  participants)  to  be  used  for  AAR. 
The  plan  was  to  have  the  OfCs  request  snapshots  from  the  operator  of  key  events  during  the 
course  of  each  exercise  run.  These  snapshots  would  aid  in  discussions  of  the  runs.  Very  few, 
if  ttiy,  requests  were  made  during  the  Hrst  few  days  of  the  mtercise.  Col.  Elder  revised  the  task 
so  that  the  Plan  View  operator  would  capture  a  snap-shot  every  half  hour  during  the  run  and 
additional  snap-shots  as  requested  directly  from  Col.  Elder.  These  snapshots  were  finally 
utilized  for  the  first  formal  AAR  on  Thursday,  May  12th  and  were  used  more  extensively 
thereafter.  A  replay  of  the  exercises  on  the  plan  view  display  at  the  stealth  station,  coordinated 
(by  "time  hack")  with  similar  displays  at  the  other  sites,  was  used  throughout  the  AARs  during 
the  second  wedc  of  the  exercise. 
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Stealth  Station/E>ata]ogger: 

The  SIMNET  6.6. 1  Datalogger  has  the  capability  of  capturing  an  entire  exercise  and  replaying 
it  through  the  network.  It  can  be  viewed  at  any  station  on  the  network  equipped  with  a  CIG 
and/or  Planned  View  Display  (PVD).  Due  to  the  technical  difficulties  eitcounteied  during  the 
preparation  week  for  the  exercise,  only  a  limited  AAR  was  performed  and  the  stealth  station  was 
not  used.  The  O/Cs  did  take  advantage  of  this  tool  during  the  actual  exercise  (second  week), 
and  key  parts  of  the  scenarios  were  replayed  and  used  during  each  AAR. 

Recommendation:  The  tools  available  to  capture  the  events  of  each  exercise  are  very  valuable 
for  AARs  and  their  use  should  be  maximized.  The  plan  view  display  allows  the  user  to  move 
through  time  at  variable  speeds  and  focus  on  key  events  during  the  course  of  the  exercise. 
These  key  time  frames  can  then  be  viewed  from  any  point  in  space  through  the  use  of  the  stealth 
station.  The  snapshots  taken  on  the  PVD  during  the  course  of  the  exercise  would  help  to 
pinpoint  these  key  events. 

Use  of  a  PDU  transmitted  from  one  stealth  station  to  control  the  point-of-view  of  other  stealths 
(or  simulator  visuals)  has  been  demonstrated.  Allowing  Col.  Elder  to  direct  the  entire 
distributed  AAR  audience's  point-of-view  of  a  particular  event  in  this  way  would  have  been 
useful. 

2.3.2.2  Unit  Performance  Assessment  System  (UPAS) 

Issue:  Data  captured  through  the  collection  tools  of  UPAS  was  used,  but  the  system’s 

capabilities  were  under-utilized. 

Discussion:  UPAS  data  were  perused  after  the  exercise,  but  not  incorporated  in  the  AAR 
during  the  first  week  of  the  exercise.  During  the  second  week  of  the  exercise,  fixe  and  kill  data 
were  provided  to  Col.  Elder  for  use  during  the  AAR.  This  data  included  number  and  type  of 
kills  for  each  CAS  mission  and  number  and  type  of  kills  for  the  entire  exercise  of  Blue  and  Red 
forces.  The  number  of  bombs  dropped  and  the  number  of  hits  by  the  FI 6s  were  also 
presented.  See  Appendix  D  for  a  sample  of  this  data.  This  information  represented  data  from 
only  two  PDU  packets;  "Fire"  and  "Vehicle  Status  Change".  Other  PDU  packets  collected 
were:  "Impact",  "Vehicle  Appearance",  "Status"  and  "Indirect  Fire".  It  should  be  noted  that  the 
lase  PDU  on  DIS  cannot  be  translated  to  SIMNET.  It  was  therefore  not  available  for  analysis 
by  UPAS. 

The  goal  of  UPAS  is  to  help  trainers  to  identify  and  illustrate  key  exercise  events  quickly  after 
an  exerci.se.  The  information  collected  by  UPAS  during  the  course  of  the  exercise  can  display 
information  in  a  way  that  supports  quick  interpretation  by  a  trainer  or  researcher,  and,  at  the 
same  time,  provides  animated  figures,  static  figures,  and  tables  that  can  be  used  to  illustrate  key 
training  points  to  exercise  participants  during  an  AAR.  It  can  be  used  subsequently  to  support 
training  needs  analysis  and  research.  Members  of  the  performance  measures  team  did  not  have 
any  opportunity  to  work  with  the  trainers  before  the  exercise.  Only  a  small  segment  of  these 
tooh  were  therefore  utilized  during  MDT2. 
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The  AAR  inform^mi  dutpley  tools  svaUsble  under  the  Dtts  Summary  menu  include  the 
folkming: 

•  Battle  Flow  (animated  figiue  >  assesses  overall  movonent) 

-  tthoesmovonentsttf  vdiiclesonagridm^) 

-  can  control  pdnts  in  time  covered  by  a  particular  trace 

•  can  speaiy  tnne  interval  at  which  vehicle  posttioos  ate  mmlced 

-  can  magnify  a  pcuikm  of  the  battlefidd 

•  Battle  Sn^Mhoi  (shows  position  and  gun  tube  orientation  M  qiecific  pdnu) 

'  select  ptrfitts  during  mission 

shows  Ltne-of-Sight  (LOS)  between  vehicles 

•  Exercise  Timdine  (describes  evetus  as  a  function  of  time) 

•  idmitify  key  time  segments 

•  Fire  Rgln  (shows  direa  and  indirect  fue  events  over  a  terrain  map) 

•  period  of  time  is  user  sekctaMe 

-  shotlines 

•  miss  is  displayed  with  a  while  liim 

•  green  is  a  hit/IdU;  dead  vehicle  ioxi  is  displayed  at  target  location 

•  artillery  impacts  are  while  nsctangles 

•  Ran  View  (rq>lays  the  battle  or  selected  segments  of  the  battle) 

•  shows  bird's  eye  view  over  a  grid  m^ 

-  torain  features  are  color  coded 

-  can  move  to  a  selected  time 

•  can  mapufy  portions  of  die  battl^eld 

-  can  (vim  a  hard  copy  at  any  point  in  time 

•  S(»een  Image  File  Disfday  (AAR  Presentmion  Manager) 

•  to  view  saved  screens  vduch  contain  trainer  conmients 

UPAS  has  many  features  which  can  be  utBiaed,  not  only  for  AARs,  but  also 
ftnr  fiirther  analysis  and  evaluations.  Hie  factual  data  it  provhles  may  not  always  be  t^^iarent 
from  die  visual  uxds  (ditained  through  die  datalt^ger,  e.g.  kill  information,  exact  dme  of  key 
events.  These  data  cmi  also  aid  in  focusing  in  on  the  time  frame  desired  for  viewing  at  die 
stealth  station. 

Ibe  key  to  propm'  vRilizadon  of  the  system  is  to  provide  a  dmefeune  far  trainers,  engineeis  and 
members  df  die  performance  measures  team  to  meet  and  discuss  tools  diat  are  availaMe  mid 
widdi  of  those  tools  can  be  effectively  used  in  an  AAR  and  focpmformance  analysis.  The  way- 
in  which  UPAS  is  used  will  vary  according  to  the  type  of  exmeise  ran.  For  example,  an 
analysis  of  the  F16s'  movemmits  via  the  Battle  Flow  di^lay  would  have  been  confusing  if  used 
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in  this  exercise,  due  die  lar:ge  number  of  flyovers.  Meat  of  the^  flydven  oocunied,  however, 
due  to  technical  difficulties  encountered  such  as  an  inability  to  see  maildng  rounds^  fi^iure  to 
get  a  "clear  hot"  in  time.  etc. 

The  only  method  of  broadcasting  UPAS  displays  to  the  various  sites  for  use  in  an  AAR  would 
have  to  be  via  video  teleconferencing  with  color  monitors,  since  these  displays  are  color  coded. 
The  monitors  usexl  at  each  site  should  be  targe  enough  to  aoccmimodate  viewing  by  a  group. 

Future  versions  of  UPAS  are  planned  on  a  woricstation  for  the  DIS  environment.  This  change 
will  upgrade  UPAS  to  a  real-time  system  and  increase  its  capabilities.  The  system  will  enable 
UPAS  to  be  used  in  the  course  of  exercise  control.  Current  status  information  can  be  relayed  to 
the  0/Cs  as  needed  and  time  markers  can  be  input  as  key  events  occur. 

2.3.3  Video  Tdeconferendng 

Issue:  All  sites  need  VTC  capability  for  AARs. 

Discussion:  The  only  video  teleconferencing  hook-up  was  between  Ft.  Knox  and  the 
Institute  for  Defense  Analysis  (IDA)  facility  in  Alexandria,  VA.  There  were  only  audio 
connections  with  the  other  sites.  The  visual  displays  provided  by  the  stealth  station  and  the  plan 
view  display  greatly  enhance  the  ability  to  provide  an  informative  and  productive  AAR.  It 
appeared  very  difficult  to  be  eflecdve  with  just  the  audio  tools. 

Recommendation:  Equip  all  stations  with  VTC  capability  for  AARs.  The  VTC  cameras  should 
be  controlled  throughout  the  AAR  by  a  local  operator  at  the  presenter  site  rather  than  just 
lingering  on  one  shot.  The  VTC  would  be  less  critical  if  the  recommendations  in  section 

2.3.2. 1  wnth  respect  to  central  control  of  Stealth/PVD  point-of-view  are  implemented. 

23.4  Scenarios 

2.3.4. 1  Exercise  Scenarios 

Issue:  Scenario  development  should  support  the  goals  of  the  training  exercise  and 

capitalize  on  the  technical  capabilities  of  the  system,  while  avoiding  "bumping  into"  system 
limits. 

Diiicu.<Mion;  The  scenarios  in  this  exercise  were  developed  without  consultation  with  the 
engineering  team  or  input  by  the  Chief  Trainer.  This  resulted  in  the  inability  to  perform  some 
aspects  of  the  scenarios,  given  some  of  the  restrictions  of  the  system,  so  revisions  had  to  be 
made.  For  example,  a  critical  technological  constraint  was  that  of  ttie  MULEs  inability  to  see 
targets  outside  its  specified  45**  cone  and  limited  to  only  5  entities.  The  MULEs  ability  to  see 
and  lase  targets  was  critical  to  achievement  of  the  training  goals 

RtacommcndaiiQn: 

'fhe  scenarios  need  to  be  developed  in  conjunction  with  die  Chief  Tirainer,  the  engineering  team 
and  the  analysis  team  with  a  focus  on  the  goals  of  the  training  exercise  and  possible  system 
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timitations.  Tlwre  needs  to  be  a  test  of  the  system  and  the  scenarios  long  haul  to  see  the 
interaction  b^ween  the  scenario  and  the  systms  at  each  participating  site.  The  analysis  team 
needs  to  imderstand  what  measures  and  tools  will  be  required  during  the  course  of  the  exercise. 

23.4.2  Syttem  Test  Scenarios 

Issue:  Small  "single  thread"  segments  of  the  actual  scenarios  should  be  used  to  perfcvm 

system  tesdng  prior  to  any  exercise. 

Di«;iL«ion;  System  testing  was  performed  prior  to  the  exercise  preparation  week  without  the 
berwfit  of  any  tactical  context  Some  problems  were  not  discovered  until  the  »;tual  scenarios 
were  exercised  on  the  long-haul  network.  This  was  due  to  the  fact  that  certain  tactical 
maneuvms  caused  problems  that  technicians  did  not  anticipate.  The  moving  model  limitations 
discussed  above  are  one  example,  as  are  the  target  acquisition  problems  encountered  by  aircraft 
flying  tactical  profiles.. 

Recommendatiftn!  The  positioning  and  movements  designated  in  different  scenarios  can 
present  their  own  unique  problems  within  the  system  with  respect  to  target  acquisition,  entity 
prioritization,  etc.  In  the  system  testing  phase  of  an  exercise,  key  "threads"  of  each  scenario 
must  be  played  to  identify  artifacts  in  the  system.  A  good  approach  would  be  to  isolate  key 
factors  in  the  scenario  and  test  them  individually.  e.g.  bombing  flight  pattern,  targets  available  to 
MULE  for  lasing,  uuget  detections/line-of-sight  evaluations,  etc. 

2.3.4.3  Assignment  of  Simulators 

Issue:  The  assignment  of  the  manned  simulators  should  correlate  widt  the  training  goals  of 

the  exercise. 

Di.<ciM.<innr  The  simulators  available  for  this  exercise  at  Ft  Knox  included  the  following:  5 
MlAl  tanks,  2  Bradleys  and  a  baseline  TCX^.  The  original  configuration  for  this  exercise 
designated  two  of  the  tanks  as  platoon  leader  vehicles  and  placed  die  FSO  and  ALO  in  the  same 
tank.  During  the  coiose  of  the  exercise,  it  was  found  that  since  the  CAS  funcuons  being  trained 
did  not  go  down  to  die  platoon  level,  this  configuradcm  of  simulators  was  not  the  most  ^ecdve. 
In  addition,  two  key  players,  the  FSO  and  ALO  had  to  share  a  radio.  Midway  through  the 
preparation  week,  the  assignment  of  simulators  was  changed  to  a  more  suitable  configuration 
ftw  each  type  of  scenario  as  represented  in  Table  2.3.4.3-1  and  Table  2.3.4.3-2. 
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Table  23.4.3*1  Defense  Simulator  Assignments 


1  DEFENSE  1 

TANK 

BRADLEY 

TOC 

TFCDR 

TFETAC 

IT  FSO 

TMCDR 

TMXO 

SCTPLTLDR 

TMFBT  ^ 

ALO 

Table  2.3.4.3*2  Offense  Simulator  Assignments 


1  OFFENSE  1 

TANK 

BRADLEY 

TOC 

TFCDR 

TFETAC 

IstSGT 

TMCDR 

TMXO 

SCTPLTLDR 

TMFBT 

ALO 

FSO 

The  ALO  operated  from  the  TOC  and  the  FSO  and  ETAC  were  placed  in  separate  tanks  for  the 
defensive  scenario.  The  FSO  also  operated  from  the  TOC  during  the  offensive  scenario  leaving 
a  tank  available  for  one  platoon  leader.  The  other  platoon  leaders  were  run  through  SAF  and  a 
Team  (TM)  Executive  Officer  (XO)  operated  in  his  own  tank.  The  FIST  now  functioned  as  a 
scout  and  traveled  with  the  other  scout  vehicle. 

Recommendation:  The  assignment  of  manned  simulators  should  be  planned  with  the  Chief 
Trainer  to  optimize  the  type  of  training  sought.  The  manned  positions  should  be  the  players 
who  are  actively  involved  in  the  exercise. 

2.3.5  Read-Ahead  Materials 

There  seems  to  have  been  sufficient  and  comprehensive  read-ahead  materials  provided  in 
advance  of  the  exercise. 
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3  BDS-D  EXIT  CRITERIA 

During  the  course  of  the  MDT2  exercise,  the  following  BDS*D  Exit  Criteria  were 
demonaraied: 

1.  Dixamilar  Sims;  The  simulators  used  in  this  exercise  at  Ft  Knox  are  SIMNET  uid 
designed  to  function  across  the  netwoik  wlwreas  the  simulators  at  the  other  three  sites  (Pax 
River.  NRaD  and  Armstrong  Labs)  were  not  originally  designed  to  be  networked  and  (xesented 
a  mixed  fidelity.  The  results  were  a  relatively  successful  integnitiem  of  the  different  systems. 

2.  Wide  Area  Netwoik  (W  ANl:  Two  of  the  sims  participating  in  MDT2,  Armstrong  and  Ft 
Knox,  used  different  Local  Area  Networks  (LANs)  and  were  successfully  connected  on  the 
WAN  to  the  other  two  iKxles.  Pax  River  and  NRaD,  who  did  not  use  a  LAN.  In  addition,  these 
sites  used  three  different  interface  units:  NIU  at  NRaD  and  Armstrong.  AIU  at  Pax  River,  and 
SIMNET  Protocol  Translator  at  Ft  Knox. 

3.  Secure  Netwoik:  This  exercise  was  conducted  entirely  over  the  secure  DSI  network. 

4.  PIS  1.0:  The  enhanced  goal  for  DIS  in  1994  is  DIS  2.0.  MDT2  achieved  DIS  2.03. 

It  should  be  noted  that  MDT2  was  not  desi^ated  as  a  demonstration  vehicle  of  BDS-D 
Advanced  Technology  Demonstration  (ATD)  architecture.  It  did,  however,  fulfill  several  criteria 
in  the  course  of  the  achieving  its  own  goal,  which  was  to  use  DIS  to  conduct  meaningful  multi¬ 
service,  combat  mission  training. 
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4  SUMMARY  AND  CONCLUSIONS 

The  main  programmatic  lesson  learned  in  the  MDT2  exercise  can  be  summed  up  as  follows: 

(1)  There  is  a  need  to  carefully  analyze  the  goals  of  joint  training  exercises,  the  technical 
capabilities  of  the  systems  which  will  be  used  through  the  Distributed  Interactive  Simulation 
network  and  the  Performance  Measures  sought  All  the  components  of  the  exercise  should  be 
viewed  as  part  of  one  system  and  the  effort  to  integrate  and  employ  diem  should  be  ied  by  one 
individual,  as  project  leader.  See  Figure  4-1. 


Engineering 


Joint  Training 
Exercise 


Analysis 

Team 


Figure  4-1  System  \^ew 


Figure  4-2  shows  the  process  involved  in  successfully  integrating  these  components.  The 
technical  capabilities  must  be  compared  with  the  behavioral  goals  sought  and  integrated  with  the 
performance  measures  desired. 
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SYSTEM  CONFIGURATION 


Tasks  *  Qoal:  Human  Behavior 


Figure  4-2  System  Coidgunition 


The  technical  infonsation  which  is  brou^t  to  the  "Jnfonnation  Exchange"  box  should  pomit 
an  in-depdi  analy^  of  the  technical  capabilities  of  each  proposed  tite  to  support  the  exercise. 
Hgme  4-3  Hats  the  categories  of  information  that  participating  simulations,  are  capable  of 
sen&ig  and  receiving. 
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SITE 

1 

1 

i 

- INFORMATION  OUT: - \ 

y''* - WWHWATIOWIN; - N 

'  lnfornu!>tion  PrevklRd  to  Simulation 

1 

f  Intonnatlon  ProcaaMKl  From  Simulatton  | 
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^  wiPowiB 
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-  nFoura 


TVr*  ol  EnHy  TM  Can  ■•  PiveMWR 
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CanlaPMaaaaaR; 

•  MHa 

-aKaMMlO 
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Figure  4«3  Tcdinlcel  CepablHlies 
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Any  simulated  entity  (entity  "A")  on  the  virtual  battlefield,  sends  infonnation  about  itself  out  to 
the  netwt^.  In  addition,  infonnation  about  the  other  entities  cm  the  battlefield  that  can  be 
processed  by  entity  "A"  are  srat  in  ftom  the  netwoiic.  A  detaited  list  of  this  infonnation  for 
every  entity  type  involved  in  the  exercise  should  be  developed.  A  systematic  analysis  of 
"infonnation  out"  and  "information  in"  should  be  perfonned  for  every  site  so  that  a  summary  of 
technical  capalnlities  available  for  the  exercise  can  be  compiled. 

This  compilation  should  be  analyzed  by  the  senior  technical,  training  and  performance  analysis 
teams  to  assess  the  system  capabilities,  m^>  them  against  operational  requirements,  and  identify 
the  shortfalls  which  may  exist.  The  solutions  to  system  shortcomings  required  may  fall  into  a 
number  of  different  categories.  There  may  be  a  feasible  technical  solution  available  to  solve  a 
training  requirement.  If  not,  a  slight  alteration  in  the  scenario  (e.g.  assuring  the  Red  vehicle 
pass  through  the  cone  of  visibility  for  the  MULE)  may  solve  a  problem.  There  may  also  be 
many  wcxrk'arounds  involving  procedural  changes  (0/C  can  provide  necessary  information  not 
available  through  the  simulation).  Finally,  there  may  be  a  necessity  to  eliminate  a  simulator,  a 
particular  player  or  evoi  a  site  if  there  is  no  odier  solution  and  die  inclusion  of  any  one  of  dtese 
interferes  with  the  exercise. 

(2)  To  ensure  that  this  system  level  approach  is  executed,  the  project  leader  (we  would  have 
nominated  Col.  Elder  in  this  case)  must  be  given  the  mission,  time  and  resources  to  put  together 
the  system,  the  scenario,  and  the  training  while  integrating  the  technical  elements  and  analysis 
requirements.  Coordination  and  planning  is  key  to  the  project's  success. 
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A/A . And-Aitcraft 

A/I . Administration/Logistics 


AAR . .....After  Action  Review 

ADA . Air  Defense  Aitilleiy 

AFAC . Airborne  Fwward  Air  Controller 

AFSC . US  Air  Force  Armstrong  Laboratory 


AiU . Adapter  Interface  Unit 

ALO. . Ar  Liaison  Officer 

ARt . US  Army  Research  Institute  for  the  Behavioral  &  Social  Sciences 

ARNO . Army  National  Guard 

ARPA . Advanced  Research  Projects  Agency  (formerly  DARPA  >  Defense 

Advanced  Reseaidi  Projects  Agency) 

ARTEP . Army  Training  and  Evaluation  Plan 

AID . Advanced  Technology  Demonstration 

BBN . Boll,  Beranek,  and  Newman 

BDA . Battle  Damage  Assessment 

Bde  or  BDE . Brigade 

BD$-D . ...Battlefield  CHstributed  Simulation  •  Developmental 

BFV . Bradley  Fighting  Vehicle  (M2  or  M3) 

BLUFOR . Blue  Forces 


Bn  or  BN . ..Battalion 

BOS . Battlefield  Operating  System 

. Command  and  Control 

CADIS . Computer  Architecture  for  Distributed  Interactive  Simulation 

CAS . Close  Ar  Support 

CAS/BA . Qose  Ar  Suppott/BattleSeld  Area  InierdictitMi 

CATS . Combined  Arms  Training  Strategy 

CDR . Commander 

CIO . Computer  Image  Generator 

CO . Commanding  Ofneer  or  Commander 

COL . . . Colonel  (06) 

CTU . Central  Processing  Unit 
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CRT.: . Cathode  Ray  Tube  (display) 

DEO . Data  Element  Dictionary 

DFO . Dqjloytd»Ie  Forward  Observer 

DIS . . . DistribiRed  Interactive  Simulation 

DMSO. . Defense  Modeling  and  Simulation  0£Boe 

DSI . ^Defense  Simulation  Internet  (uses  the  DIS  protocols) 

ETAC . „.EnlisiBd  Terminal  Attack  Oontrcdler 

FAC . Forward  Air  Contrcdler 

FIST . ..Rre  Support  Team 

FIST-V . Fire  Support  Team  Vehicle 

FLOT. . . . Jk>rward  Line  of  Troths 

FOV . Field-of-Vicw 

FSE . Fire  Support  Element 

FSE. . Fonvaid  Security  Element 

FSO . Fire  Support  Officer 

HMD . Helmet-Mounted  Display  (or  Head  Mounted  Display) 

HumRRO . Human  Resources  Research  Organization 

IDA . Institute  for  Defense  Analysis 

II . Illusion,  Inc. 

LAN . Local  Area  Network 

LDN . Local  Data  Network 

LHN . Long  Haul  Network 

LOS . . Une-of-Sight 

Ml  A1 . Alnams  Main  Battle  Tank  (120  mm  main  gun) 

M2 . Bradley  Infantry  R^tmg  Vehicle  (DFV) 

M3 . Bradley  Cavalry  Fighting  Vehicle  (CFV) 

MAJ . .Major  (04) 

MB  AG . Main  Body  of  die  Advance  Guard 

MDT2 . Multi-service  Distributed  Training  Te^bed 

MLRS . Jdtdtiple  Laimcher  Rocker  System 

MU1£ . .Mariiw  Ground  Laser  Designator 

MWTB . Mounted  Warfare  Test  Bed,  FL  Knox.  KY 

-  NTC..... . ....Naval  Training  Center 

NAWC/TSD . l^val  Air  Warfare  Center.  Training  Systems  Division 


NIU  - - 1.... — Ndwodc  bterfoce  Ue^ 

NRaO . Reaeardi,  Oevelt^Miwit,  Test  and  EvaloadtHi  Division  of  the  Naval 

Ctnninand,  Control  and  Ocean  Surveillance  Center.  San  Diego.  CA 

0/C . Ctoserver/Controller 

OP . Observation  Post 

OPFOR . Opposing  Forces 

OPORD . Operations  Order 

OTW . Out-nw-Window 

PAX . Systems  Engineering  Test  Directorate,  Patuxant  River.  MD 

PC . Personal  Computer 

PDU . Protocol  Data  Unit 

PL . Platoon  Leader 

Pit . Platoon 

PM . Program  Manager 

POC . Point  of  Contact 

POSNA V . Position  Navigation 

PT . Protocol  Translator 

PVD . Plan  View  Display 

ROE . Rules  of  Engagement 

S-2 . Battalion  Intelligence  Officer 

S-3 . Battalion  Operations  &  Training  Officer 

SAF . Semi-Automated  Forces  (syncrnymous  with  Computer  GetMerated 

Forces) 

SAFOR. . Semi-Automated  Fences 

SAM . Surface  to  Air  Missile 

SCT . Section  Leader 

SEAD . Suppression  of  Enemy  Air  Defense 

SIMNET. . Simulation  Network 

SINCGARS . Single  Channel  Ground  and  Airborne  Radio  System 

SP . Software  Problem 

STARTEX . Start  Time  of  Exercise 

STRICOM . US  Army  Simulation,  Training  and  Instrumentatitm  Command.  Orlando. 

FL 

T-72 . Tank  (Soviet) 

TACP. . . . Tactical  Air  Control  Party 
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TC . .Tank  Omunander  (in  Ml)  or  Tni^  Ckanmander  (m  M2/3) 

TF . . . .Task  Force 

TM . .Tena  Leader 

TOC.... . .Tactical  Operations  Center 

TOW . Tube  hunched.  Optically  tradced,  Wue  glided  (missile) 

UPAS . . Umt  Performance  Assessment  System 

V&V . Verification  imd  Vdkhtion 

VTC . Video  Telecoirieience 

WAN . Wide  Area  Network 

WDL . Western  Devdopment  Laborattmes  (a  Loral  Company) 

W  P . While  Phosphorus 

XO . Executive  Officer 


APPENDIX  B:  PORT  KNOX  PARTICIPANTS 


Seni(K  Ob«mcr/Comrollers/TRuncts: 

•  COL  Don  Elder,  Anny,  Seniot  Trainer 

•  Jim  Love,  Assistant 

•  COL  Mike  Rodriguez,  Air  Force,  Air  Trainer 

•  Major  Mark  McKeon,  Marines.  Assistant 

•  Paul  Jcrett.  Assistant.  HUMRRO 

Researchers/Data  Compilers: 

•  Dan  Dwyer,  NAWC/TSD 

•  Lany  Meliza,  USARI  Orlando 

•  Angelo  Mirabeila,  ARI 

•  Seng  Tan,  Institute  for  Simulatiwi  and  Training 

•  Joyce  Madden,  NAWC/TSD 

•  Larry  Rieger,  US  Army  Training  Support  Center 

Technica]: 

•  Steve  Farrow,  LORAL,  ADST  PMO 
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16  May  1994 


MEMORANDUM  FOR  THE  RECORD 

SUBJECT:  Enptct  of  DSlNet  on  the  Multi<Sefvice  Distributed  Training  Testbed  (MDT2) 


1.  During  the  week  of  9  May  1994,  the  MuM-Service  Distributed  Training  Testbed  (MDT2} 
used  the  Distribute  Simulation  Internet  (DSINet)  for  preliminary  tests  of  its  capability  to 
stq>p«t  training  of  Qose  Air  Scqpport.  This  is  part  of  the  four-Service  project,  support^.by  the 
Defense  ModeBng  and  Simulation  OfOce  (DN^O),  to  demonstrate  the  value  that  distributed 
simulatioa  caaadd  to  joint  training.  While  the  DSINet  could  be  a  good  asset,  its  reliability  was 
disqqrointing. 

a.  DMSO  axid  ARPA  prt^nents  of  the  MDT2  proposal  said  in  November  1992  that  the 
DSINet  was  capable  of  supporting  such  multi-point  distributed  training  requirements.  My 
current  data  do  not  support  that  claim. 

b.  Explanadons  for  poor  netwodc  reliability  are  unclear  as  I  write  this  memo.  MDTZis 
conductiog  engjineeiing  tests  this  week  to  try  and  isolate  the  problems.  All  neewode  contractors 
including  BBN  and  Houston  Associates  are  cooperating  within  the  constraints  of  their  contracts. 

2.  We  required  a  multi-point  coimection  of  four  sites  with  a  total  of  only  60  moving  entities  and 
four  channels  of  <Egiul  voice.  Eleven  simulators  were  connected  among  the  sites.  MDT2 
scheduled  nine;  houn  per  day  for  four  days  on  the  DSINet  Network  availability  was 
UBpredktable  and  materialhed  for  only  about  60  percent  of  tlm  scheduled  36  hours.  The 
problems  occuesed  even  though  the  network  was  mx  heavfly  loaded.  Little  to  no  training  could 
be  accQoplisbed  with  the  DSlNet's  perfonnance. 

3.  MDT2  win  proceed  with  its  scheduted  training  Mtreise  during  the  week  of  23  May  1994. 

AH  juuikipints  express  enthusiasm  for  its  potential  and  hope  for  its  success.  The  training 
requites  netwondt  time  firom  0800  to  1800  each  of  the  five  days  to  allow  connectivity  tests, 
training  exerdses.  dam  collection/analyses,  and  After  Acdon  Reviews. 

a.  On  24  May  19S14.  the  Marines  and  MDTl  simultaneously  plan  multi-point  use  of  different 
parts  of  the  DSINet  The  Marines  have  scheduled  a  ttemonstiatioo  of  the  technology  for  genetal 
ctfficm  and  odser  high  ranking  offidab.  MDT2  invited  Congc^onal  observers,  senior 
personnel  from  ilie  servwesjod  from  OSD  to  see  training  from  a  node  at  the  Insiicute  for 
Defense  Analyaes,  Atotandiia,  VA.  The  networic  engineers  say  that  dte  system  is  designed  for 


C-2 


AOST/WDiyrR-M>WQ08312  DT2L«Mn»L«nrf 

aOjumUM  VtnfaBlO 

PEBl-n 

SUIUBCT:  Impact  of  DSZKet  on  the  Multi-Service  Distributed  Training  Testbed  (MDT2) 


such  dual  use  if  it  is  woridng  and  pioperiy  inidaliaed.  but  there  seem  to  be  frequent  inidiUzadoo 
problems. 

b.  Another  coneero  is  that  networic  perftMmance  during  almost  two  months  before  last  week 
was  not  even  60  percent  reliable.  Contracton  who  operate  the  networic  and  users  e:q)erimiced 
widk  it  ten  me  that  reliabilicy  for  tests  always  is  better  than  during  preparations  when  the  need  is 
less  critical 


4.  n  appears  that  the  technology  cunently  in  use  by  the  DSINet  is  not  capable  of  routinely 
sui^pofting  MDT2‘s  multi-point  training  application.  However,  the  technology  will  irever  be 
ready  unless  MDT2  and  similar  projects  continue  to  test  its  capabilities  and  thereby  foster  better 
perfmmance. 

a.  So  far,  the  network  weU  supports  technology  demonstrations  as  a  primary  focus.  Those 
demtmstrations  can  work  less  than  perfectly  and  still  be  successful.  In  a  training  application,  the 
participants  need  to  focus  on  the  training  objectives  without  distractions  from  network  problems. 


b.  MDT2  faces  the  uneaqiected  challenge  of  pushing  network  technology  in  support  of  a 
training  goal  in  addition  to  testing  the  value  of  distributed  simulation  for  training.  Why  is  the 

net  not  as  ready  as  advertised?  W  *fcnf  T  mn  )v»n^r  rhat  q»«»<Tmn  mnre - g 

enpalLm.!.  irexi’'tWBil  muIduiUtg  tite  MDTl's  sLbeUuleU  PltasrT  ituiuug  lit  July  199rt - 


^07*^  - 


FRANKLIN  L.  MOSES 
MDT2  Project  Leader 
Training  Systems  Research  Division 
US  Army  Research  Institute 
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DT2  Lessons  Learned 
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LOG  OF  FIS  FIRING  EVENTS 


TINE  FXRER  ID 

FIRER  LPN 

RESULT 

LOCATION 

AMMO 

12:52:49 

14.4.6 

K 

N58S6K0368 

US  CBUIO  B< 

12:53:23 

14.2.6 

H 

N5857K0369 

US  GBUIO  B- 

12:54:54 

14.2.6 

M 

NS8S6K0369 

*  •  US  CBUIO  B 

13:10:44 

14.2.6 

M 

N5691K03S9 

*  '  US  GBUIO  S 

13:28:08 

14.4.6 

H 

NS479K0147 

US  GBUIO  P 

13:28:08 

14.4.6 

H 

N5479K0147 

US  CBUIO  E 

13:30:12 

14.2.6 

K 

N5S05K0193 

US  CBUIO  B 

13:30:12 

14.2.6 

H 

N5505K0193 

US  GBUIO  B 

13:30:41 

14.4.6 

H 

N5514X0213 

US  CBUIO  B 

13:43:59 

14.4.6 

.M 

N5550K0272 

US  GBUIO  E 

LOG  OF  FI 6  M ITS/KILLS 


TI.ME  FIBER  ID 

FIKLB  LPN 

RE.5UI.T 

TARGET  TYPE 

12:52:49 

14.4.6 

K 

USSR  T72M 

12:53:23 

14.2.6 

H 

USSR  T72.n 

13:28:08 

14.4.6 

K 

USSR  BHP2 

13:28:08 

14.4.6 

H 

USSR  BHP2 

13:30:12 

14.2.6 

K 

USSR  BMP2 

13:30:12 

14.2.6 

H 

USSR  BMP2 
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1*4:  SO: 51  B 
12:51:19  B 
12:53:01  B 
12:54:26  B 
12:55:50  B 
12:57:58  B 
12:68:15  B 
13:07:24  B 
13:22:57  R 
13:22:59  R 
13:22:59  R 
13:23:00  R 
13:23:01  R 
13:25:15  B 
13:28:45  0 
13:29:50  B 
13:30:30  B 
13:34:27  B 
13:34:40  0 
13:31:47  B 
13:  34  :4  9  il 
13:31:55  B 
13:34:55  B 
13:34:57  H 
13:34:57  B 
13:34:57  B 
13:34:59  B 
13:36:03  R 
13:35:10  R 
13:35:13  B 
13:35:18  B 
13:35:26  R 
13:35:27  B 
13:35:30  R 
13:35:37  R 
13:35:38  R 
13:35:40  B 
13:35:40  f< 
13:33:42  R 
13:35:46  B 
13:35:54  B 
13:35:55  U 
13:36:06  8 
13:36:17  B 
13:36:19  B 
13:36:24  8 
1.1:36:24  B 
13:36:25  B 
13:36:23  B 
13:38:25  R 
13:36:31  B 
13:36:31  B 
13:16:32  B 
13:36:32  B 
13:36:33  R 
13:36:33  B 


US  Fiec 
US  F16C 
US  F16C 

US  nec 
US  Fiec 
US  F16C 
US  F16C 
US  H2 
USSR  BHP2 
USSR  T72H 
USSR  T72H 
USSR  BMP2 
USSR  BHP2 
US  F18C 
US  AlO 
US  AlO 
US  F16C 
US  Ml 
VS  Ml 
US  M2 
US  M2 
US  M2 
US  M2 
US  M2 
US  H2 
US  M2 
US  M2 
USSR  BHP2 
USSR  BMP2 
US  HI 
US  HI 
USSR  T72.M 
US  Ml 
USSR  T72M 
USSR  T72M 
USSR  T72M 
US  HI 
USSR  T72.M 
USSR  T72M 
US  Ml 
US  M2 
US  Ml 
US  Ml 
US  HI 
US  Ml 
US  Ml 
US  HI 
US  Ml 
US  Ml 
US  Ml 
US  Ml 
US  Ml 

W”.\ 

us  Ml 

MS  Ml 


H 

H 

H 

K 

K 

K 

K 

K 

H 

H 

K 

H 

K 

II 

H 

H 

H 

M 

M 

K 

If 

H 

K 

H 

H 

K 

H 

K 

H 

M 

H 

K 

H 

M 

M 

K 

K 

H 

M 

M 

H 

M 

M 

.M 

H 

K 

K 

II 

H 

M 

K 

H 

H 

M 

K 


PAX-OVIO 

PAX-OVIO 

H66 

KSG 

A12 

A12 

A14 

All 

A12 

AM 

All 

A12 


H65 


A65 


A65 


H66 
H7l 
A65 
H66 
a65 
A31 
A31 
A34 
A3  2 
A33 
K65 
A33 
A34 
A3  2 
ASS 
A31 

WAS 


All 

All 

AM 

A12 

A12 
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kit/kills  iy  ftrxmg  side, weapon  type 

SIDE  WEAPON  SYSTEM  i  HITS  OR  KILLS 


B 

B 

B 

B 

R 

R 

R 


US  AID 
US  FISC 
US  Ml 
US  M2 
USSR  BMP2 
USSR  T72H 
USSR  ZSU23.4H 


0 

9 

14 

4 
3 

5 
1 


•sr 


CASUALTIES  SUSTAINED  (KIT  OR  KILLED) 


SIDE  TARGET  VEHICLE  TYPE  CASUALTIES 


B 

US  AlO 

1 

B 

US  Ml 

3 

B 

US  HZ 

3 

R 

* 

USSR  BHPZ 

10 

R 

USSR  T72M 

9 

R 

USSR  ZSU23_4M 

2 

D-4 


FIRES  OVER  TIME  (NO  ADA) 


TIME 

FIRING  SIDE  FIRING  WEAPON 

RESULT  FI HER  ID 

TARGET  ID 

13 

36 

43 

B 

US 

hi 

H 

A31 

ADA-1 

13 

36 

43 

B 

US 

HI 

H 

A34 

ADA-1 

13 

37 

02 

B 

US 

HI 

H 

K65 

13 

37 

03 

B 

US 

Ml 

M 

A65 

13 

37 

16 

B 

US 

HI 

H 

A65 

13 

37 

34 

B 

US 

Ml 

H 

a65 

13 

37 

33 

B 

US 

Ml 

H 

H66 

13 

37 

53 

0 

US 

Ml 

H 

K&6 

13 

38 

07 

B 

US 

HI 

M 

Hee 

13 

38 

18 

a 

US 

Ml 

H 

K6S 

13 

38 

27 

Q 

US 

Ml 

H 

H65 

ADA-1 

13 

38 

30 

B 

US 

Ml 

K 

a31 

13 

36 

36 

D 

.US 

Ml 

K 

A3  3 

13 

38 

36 

n 

US 

Ml 

K 

A34 

13 

38 

36 

8 

US 

Ml 

H 

A65 

13 

38 

37 

R 

USSR 

BMP2 

It 

HS5 

13 

38 

39 

B 

US 

Ml 

H 

A31 

13 

38 

43 

R 

USSR 

BHP2 

K 

A65 

K65 

13 

38 

45 

B 

US 

HI 

M 

ADA-2 

13 

39 

05 

B 

US 

Ml 

K 

ASS 

13 

39 

17 

B 

US 

Ml 

H 

A65 

13 

41 

23 

B 

US 

HI 

H 

A21 

13 

41 

28 

D 

US 

Ml 

K 

A33 

A34 

13 

41 

28 

R 

USSR 

T72M 

K 

A21 

13 

41 

29 

B 

US 

HI 

H 

13 

41 

33 

B 

US 

Ml 

K 

A31 

13 

41 

33 

B 

US 

Ml 

H 

Kee 

13 

41 

34 

b 

US 

Ml 

H 

A21 

13 

41 

34 

B 

US 

HI 

K 

A33 

A31 

13 

41 

37 

R 

USSR 

T72H 

K 

13 

41 

37 

R 

USSR 

T72M 

« 

13 

•11 

40 

n 

US 

HI 

II 

AZl 

13 

41 

40 

B 

US 

HI 

K 

A33 

13 

41 

41 

B 

US 

Ml 

H 

K66 

13 

41 

45 

B 

US 

Ml 

K 

A32 

13 

41 

46 

B 

US 

Ml 

K 

A33 

)3 

4A 

20 

B 

US 

HI 

M 

A65 

13 

16 

31 

B 

US 

HI 

H 

A65 

13 

4C 

4  1 

B 

US 

Ml 

M 

a65 

